Qbi's Weblog

In einem Beitrag vor ein paar Tagen kam ich zu der Ansicht, dass spätestens mit der Anwendung der Datenschutz-Grundverordnung am 25. Mai 2018 Flickr nicht mehr genutzt werden kann. Das bedeutete für mich, dass ich mein Blog auf Bilder prüfen muss, die über Flickt eingebunden werden. Soweit ich das sehe, ist das jetzt abgeschlossen. Es sollten keine Bilder mehr über Flickr und andere fremde Quellen kommen.

Weiterhin habe ich geprüft, ob ich bei YouTube-Videos die Domain youtube-nocookie.com verwende. Auch dies sollte jetzt der Fall sein. Damit kommen die Videos hier im Blog entweder von obiger YouTube-Seite oder von media.ccc.de.

Solltet ihr noch Sachen finden, die von woanders eingebunden werden, freue ich mich über einen Hinweis in den Kommentaren.

Anfang März 2018 finden wieder die Chemnitzer Linux-Tage (auch als Onion Service) statt. Traditionell organisiere ich die Keysigning-Party. Die Anmeldung dafür ist abgeschlossen und ich habe eine Grafik für das Web of Trust erstellt:

Ich habe meine Anleitung zur Installation und Benutzung von Minilock mal verfilmt:

Ich habe in den letzten Tagen ein wenig mit Infosec Bytes zusammengearbeitet. Die Organisation enstammt dem Centre for Investigative Journalism und möchte anderen Journalisten Trainings im sicheren Umgang mit dem Rechner und dem Netz bieten. Hierzu wurden eine Reihe von Videos veröffentlicht, andere Publikationen sind noch in der Pipeline.

Hier findet ihr beispielsweise eine kleine Einführung zu Tor:

Why journalists and whistleblowers need to understand infosecurity

Ich hatte heute den verwegenen Plan und wollte die Webseite des sächsischen Landtages per HTTPS aufrufen. Der Browser stoppte mich und zeigte eine schöne Fehlermeldung:

Also dem Zertifikat traut der Browser nicht. Außerdem fehlen dem weitere Bestandteile. Das Zertifikat ist eigentlich für eine andere Domain und schon längst abgelaufen.

Hier frage ich mich, ob jemand schon mal eine Liste von Zertifikatsfehlern gesehen hat, die länger ist, als die obige.

Am 19. und 20. März fanden in Chemnitz wieder die Chemnitzer Linux-Tage statt. Einer alten Tradition folgend organisierte ich das Keysigning. Das heißt, Leute mit einem OpenPGP-Schlüssel können teilnehmen und sich gegenseitig ihre Identität bestätigen. Durch die Prüfung und Signatur wird das Vertrauensnetz (Web of Trust) gestärkt.

In den letzten Jahren stellten wir uns dazu in einer Reihe auf. Die erste Person bewegte sich dann zur zweiten und anschließend zur dritten, vierten usw. Nachdem die erste Person vorbei war, fing die zweite an. So sah das ungefähr aus:

Startaufstellung:

1

2

3

4

5

6

7

8

9

10

Erste Person startet:

2	3	4	5	6	7	8	9	10
1

Zweite Person startet:

3	4	5	6	7	8	9	10
2	1

Nach einer Weile startet die sechste Person:

7	8	9	10	1
6	5	4	3	2

Das heißt, die erste Person reiht sich wieder ans das Ende ein. Eine Reihe zeigt jeweils den Ausweis und die andere Reihe vergleicht.

Bei dem Verfahren ist nun der Nachteil, dass anfangs sehr viele Leute im Leerlauf sind. Sie müssen warten, bis die erste Person endlich bei denen angekommen ist. Um dies ein wenig zu beschleunigen, haben wir die Reihe dieses Jahr direkt gefaltet. Nach der Sortierung in eine Reihe stellten sich alle gegenüber auf:

1	2	3	4	5
10	9	8	7	6

Die Idee war, dass wieder eine Reihe prüft und die andere den Ausweis zeigt. Leider habe ich das wohl nicht genau genug erklärt und es wurde parallel von beiden Seiten gemacht. Als die Reihe nun zur Hälfte abgearbeitet war, kamen die Teilnehmer bei ursprünglichen Gegenüber wieder an und nahmen an, alle erwischt zu haben. Dies ist aber nicht der Fall:

2	3	4	5	6
1	10	9	8	7

Die Aufstellung oben ist nach dem ersten Wechsel. In der initialen Aufstellung verglich beispielsweise Teilnehmer 3 mit Teilnehmer 8 die Daten. In obigem Schritt vergleicht 3 mit 10 usw. Nach fünf Schritten stehen sich 3 und 8 wieder gegenüber. Teilnehmer 3 hat dann die Identität der Teilnehmer 8, 10, 2, 4 und 6 verifiziert. Was ist mit 1, 5, 7 und 9? Diese fehlen offensichtlich. Es kostete mich einige Mühe die Teilnehmer zu überzeugen, dass der Lauf noch nicht beendet ist. Hoffentlich kann ich alle dann im nächsten Jahr auf diese Seite verweisen und die Überzeugungsarbeit wird einfacher.

Wer sich für den Stand des Web of Trust interessiert:

Viele von euch kennen vielleicht die Seite SSLLabs.com, bei der sich die Einstellungen bezüglich TLS testen lassen. Wer wissen möchte, wie gut die Daten auf einer verschlüsselten Webseite geschützt sind, kann den Namen eingeben und SSLabs führt dann verschiedene Tests durch. Nach Beendigung gibt die Seite eine Einschätzung aus.

Nun ist TLS nicht die einzige Baustelle, was die Sicherheit im Web betrifft. Es gibt zahlreiche Schwachstellen, die ausgenutzt werden. Für einige dieser Schwachstellen wurden neue HTTP-Header eingeführt.

So gibt es beispielsweise einen, der dem Browser auffordert, die Seite ausschließlich über HTTPS aufzusuchen (HSTS). Die meisten aktuellen Browser unterstützen den Header. Daneben gibt es Header, die Schutz vor so genanntem Cross-Site-Scripting (XSS) bieten sollen sowie weitere mehr.

Die Seite securityheaders.io hat es sich zum Ziel gemacht, die Header der Webseiten zu testen und ein ähnliches Rating wie SSLLabs auszugeben. Auch hier erhaltet ihr einen schnellen Überblick über die Sicherungsmaßnahmen. Allerdings habe ich Einstellungen gefunden, wo das Rating aus meiner Sicht nicht gerechtfertigt ist. Die Seite hatte HSTS gesetzt und erhielt trotzdem nur ein sehr schlechtes Rating. Laut Aussage der Entwickler sind die aber dabei, das zu ändern. Testet die Seite doch mal aus!

Meine Seite hat derzeit folgendes Rating:

Wie ihr seht, fehlt derzeit CSP und das Key Pinning. Bei letzterem lässt sich aus meiner Sicht viel falsch machen. Da will ich erstmal noch ein paar Gedanken reinstecken, bevor ich den setze. Und CSP muss ich testen, inwieweit das mit dem Blog Probleme gibt. Wenn das passiert ist, steht einem A+ nichts mehr im Wege.